Home

Design & Testing

Chess Tiles

Two iterations of the chess tiles were created. In the first iteration, all chess tiles were 3D printed individually, including the tiles used to house the captured pieces, and connected together using dovetail joints. Each of the tiles have holes for a hall effect sensor for ease of connecting all of the VCC, OUT, and GND pins with copper wires. Wire insulators were placed to ensure no copper wires from different signal lines touched. Because all of the tiles were printed individually, some of the tiles sometimes popped up, introducing grooves that caused chess pieces to trip or get stuck when being moved by the payload. To solve this issue, we utilized a 3D printer capable of loading in two different colors at once to print 16 tiles (8 black and 8 white) as a single unit. This ensured that more of the tiles were in line with each other – which we found worked better in terms of allowing smooth piece movement across its surfaces. An 1-to-8 mux and an 8-to-1 mux were used to power columns and read the output from rows respectively – in an effort to reduce the number of GPIO needed from 64 to 16. Whenever the current state of the board was updated, the Raspberry Pi would power one column at a time, then write a 1 to its corresponding output’s location in an 8x8 array.

Chess pieces

The chess pieces were a remix from a set available on Thingiverse that required no support. Holes the size and depth of one magnet were created at the bottom of our chess pieces so that the magnets sat flush with the tiles. Upon testing movement between tiles with a magnet underneath the board, we found that the magnets we ordered were too strong – to the point where passing pieces in the middle of tiles caused adjacent chess pieces to attract.

We experimentally heated up the magnets for different intervals using a soldering iron to permanently weaken them, until we came across a magnet strength that would attract to the payload magnet below when actuated but weak enough to avoid attracting adjacent chess pieces. We found that heating the magnets at 180°C for 10 seconds then doubling the magnets within each chess weak provided a magnetic strength that met our requirements. This method of adjusting the magnet strength proved very hard to standardize, so there were inconsistencies with the actuation mechanism.

Chess API

The python-chess library and the Stockfish chess engine were used to handle CPU move generation, user input move validation, and current chess board display. This library also allowed access to the type of pieces at each location using the fen function.The library accepts or outputs strings [initial location][final location] as moves – more details on how we translate between move inputs and physical chess movements will be discussed in the following sections. We first ran into issues where running the command sudo python [filename].py would result in the ModuleNotFoundError for python-chess or RPi.GPIO library. We found that it was because the python-chess was not installed on the sudo path, but the GPIO pins required sudo permissions. To fix this, we ran the command sudo -E python [filename].py to keep the environment.

User Inputs by Chess Pieces

The python-chess library takes user inputs as a string in the form [initial location][final location]. In the first iteration of translating user movement of physical pieces to a string, we kept track of the total number of pieces detected by hall effect sensors on the board. Having one less piece on the board and then another piece reappearing would signify that a piece on the user’s side was picked up and placed down. Those two locations in the array would then be translated to their respective tile locations and casted into a string for the python-chess API to take.

However, the major flaw with this approach was the difficulty in differentiating between when the user only wants to move a piece or if the user wants to capture a CPU’s piece. Capturing a piece would be registered as an always invalid move for the user. In a capture, the reading of only one hall effect sensor changes, which meant additional data needed to be included to indicate what kind of move happened.

Instead, our second iteration of the user input code utilized the fen function to create an 8x8 array with the piece types in each tile on the board and check whether the piece picked up by the user was a personal or opponent piece via the isUpper function, where an uppercase letter would signify that the piece picked up was the opponent’s. When a piece is picked up, the code would check who the piece belonged to. If it belonged to the opponent, it would register a capture, and would change the input into the library to accommodate the fact only one location has changed.

2D Plotter Design

A 2D plotter was created to allow the payload to move in the x and y directions, similar to a 3D printer. This plotter would only utilize two stepper motors, and using a pulley, and changing the directions the stepper turned, could create movement in both axes. To minimize cost, we originally used only the rods the payload would move on to support the structure. However, initial testing showed the whole system to be unstable, so two extrusions were added to stabilize the whole plotter. The midbody was also susceptible to being shifted inconsistently, so two ball bearings per midbody were included for stability. Due to the nature of the plotter, the x axis movement rods needed to be tightly secured, so the midbody was printed in two parts, then screwed together as tightly as possible to press the rods fit.

Two encoders were used to help keep track of the 2D plotter’s location on the chess board. One horizontal strip and vertical strip of magnets are placed strategically to correspond with the distances between each tile in the x and y direction. A hall effect sensor is attached to the payload such that detecting a magnet would mean that the payload moved the distance of one tile in its current direction for the x and y direction.

Assembled 2D plotter with payload.

Payload Design & Actuation

A rack and pinion is embedded within the payload, with one end of the pinion attached to the magnet for two purposes when actuated – to move chess pieces from that tile to the destination and to calibrate the payload to the center of the tile. During the calibration process, the magnet would be actuated to within the range of the hall effect sensor, and the payload would move in a swirl-like pattern until it finds the hall effect sensor of the tile it is supposed to be on. This was necessary because inconsistent motor speeds and the size of the magnet meant we could not pinpoint exactly where the center of the tile was. We ran into issues with the magnet on the payload being too strong and causing pieces to move erroneously, even when not actuated. This was never fixed, since the time didn’t allow us to buy and test new magnets, or redesign the entire actuation mechanism.

Pictures of the payload unactuated (left) and actuated (right).

Schematic of All Components

Electrical connections of Raspberry Pi, motor drivers, payload encoders and voltage regulator.

Chess tile hall effect sensor, optoisolators, and mux connections.

Results

Our team was able to do the following consistently in isolation:

1. Embed hall effect sensors into each of the 64 tiles of the chess board so that the system can detect what pieces were moved and to where via digital hall effect sensors. This allows the user to play a chess game against stockfish by manually moving their own and stockfish’s chess pieces. The user’s moves are detected automatically based on the pieces that disappear and reappear on the board. Stockfish’s moves are displayed in the python terminal and the game does not progress until that piece is detected on the correct tile.

2. Design a 2D plotter that can move pieces across a 8 x 10 grid using an array encoder feedback for exact positional tuning. Ten magnets are each laid out in the horizontal and vertical direction, corresponding to the distance that each tile’s center is away from the next adjacent tiles. The encoder utilizes these magnets to move to the approximate location of the desired tile. Once the payload has moved to the approximate location of the desired tile, the magnet on the payload is actuated and the payload moves in an increasingly larger square, similar to 3D printing calibration, to help the payload center itself in the tile. The payload is “centered” when a magnet on the payload causes the hall effect sensor in the corresponding tile to register a HIGH.

3. Attach a magnet to a DC motor in the payload. The DC motor mechanically actuates the magnet so that the plotter can move the pieces around the board from under it.

Although these features do work in isolation, we ran into issues which ultimately lead to us unsuccessfully integrating the system. Namely:

1. The magnets that we purchased were too strong. Their initial strength was sufficient to be detected by the hall effect sensors in the tiles. However, given the placement of the pieces and the movements capable by the 2D plotter, chess pieces could only be moved via manhattan distances – resulting in cases where chess pieces would come close to other chess pieces. This would cause some pieces to attract to each other and then displace.

2. Rattling of the 2D plotter caused the board to vibrate – which resulted in chess pieces displacing and the hall effect sensors no longer detecting them.

Conclusion

Our project was able to achieve two main features. First, we were able to play a full game with stockfish by manually moving our own and stockfish’s pieces. The only input required for the user’s turn is to pick up and place their piece down on a tile. Stockfish’s turn would be displayed on the terminal and the user would be responsible for moving its pieces. Invalid moves or incorrect placement of stockfish’s pieces would result in the game waiting until the move has been corrected. Second, we were able to demonstrate that when only a few chess pieces on the board and a user input their move into the terminal as a string. The 2D plotter was able to pick up the piece that Stockfish wanted to play and moved it to its final destination.

Having all of the chess pieces on the board and the 2D plotter actuating Stockfish’s pieces definitely did not work because of the rattling that the plotter did during the movements and because the magnets’ strengths under the chess pieces were variable. This caused pieces to displace prematurely and would cause the system to erroneously detect user chess inputs.

Future Work

If given the opportunity to work on this project for more time, we would work on acquiring magnets that fit our requirements. The magnets that we purchased were strong enough to be detected by the hall effect sensors in the tiles. However, when pieces were moved using the magnet on the payload, the pieces had to pass through other pieces, causing the pieces to attract to each other. This ultimately caused many pieces to displace. Thus, we would focus on integrating magnets with a strength strong enough to be detected by the hall effect sensor but weak enough to not be attracted to other pieces that are approximately 3 mm away from it. Another solution could also be to scale up the chess tiles and the 2D plotter to give more space between the pieces when moving.

Item	Number Used	Total Price ($)
Stepper Motor	2	17
Stepper Motor Driver	2	5.60
8 mm 400 mm rod	4	17.99
LM8UU Bearing	6	5.46
GT2 Pulley	2	2.80
Pully Belt	2	1.32
A3144 Hall Effect Sensor	66	21.42
1/8'' magnets	20	4.40
Extrusions	2	9.00
Opto-isolator	8	3.52
5V regulator	1	1.07
8-1 Mux (74AC151PC)	1	1.06
1-8 Mux	1	1.08
Chess Piece Magnets	32	2.66

Autonomous Chess

Introduction

Demo Video

Design & Testing

Results

Conclusion

Future Work

Bill Of Materials

Code

References

Thanks for stopping by!